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Dynamic Allocation of Shared IPv4 Addresses 
Abstract 


This memo describes the dynamic allocation of shared IPv4 addresses 
to clients using DHCPv4. Address sharing allows a single IPv4 
address to be allocated to multiple active clients simultaneously, 
with each client being differentiated by a unique set of transport- 
layer source port numbers. The necessary changes to existing DHCPv4 
Client and server behavior are described, and a new DHCPv4 option for 
provisioning clients with shared IPv4 addresses is included. 


Due to the nature of IP address sharing, some limitations to its 
applicability are necessary. This memo describes these limitations 
and recommends suitable architectures and technologies where address 
sharing may be utilized. 

Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7618. 
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Copyright Notice 


Copyright (c) 2015 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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Introduction 


The shortage of available public IPv4 addresses means that it is not 
always possible for operators to allocate a full IPv4 address to 
every connected device. This problem is particularly acute while an 
operator is migrating from their existing, native IPv4 network to a 
native IPv6 network with IPv4 provided as an overlay service. During 
this phase, public IPv4 addresses are needed to provide for both 
existing and transition networks. 


Two main types of solutions have emerged to address the problem (see 
Appendix A of [RFC6269]): 


1. Deploying Carrier-Grade Network Address Translation devices 
(CGNs) [RFC6888]. 


2. Distributing the same public IPv4 address to multiple clients 
differentiated by non-overlapping Layer 4 port sets. 


This memo focuses on the second category of solutions. 


[RFC7341] introduces a "DHCP 406 server", which offers dynamic 
leasing for IPv4 addresses to clients as described in DHCPv4 
[RFC2131], but transported within a DHCPv6 message flow. This memo 
specifies a new DHCPv4 option -- OPTION V4 PORTPARAMS -- and 
describes how it can be used for the dynamic leasing of shared IPv4 
addresses. 


Although DHCPv4 over DHCPv6 is used as the underlying DHCPv4 
transport mechanism throughout this document, OPTION V4 PORTPARAMS as 
a DHCPv4 option may also be used in other solutions, if required. 


Applicability Statement 


The solution allows multiple hosts to be simultaneously allocated the 
same IP address. As the IP address is no longer a unique identifier 
for a host, this solution is only suitable for specific architectures 
based on the Address plus Port model (A+P) [RFC6346]. Specifically, 
this document presents a solution that applies to [RFC7596] and 
certain configurations of [RFC7597] (e.g., Embedded Address bit 
(EA-bit) length set to 0). 


The solution should only be used on point-to-point links, tunnels, 
and/or in environments where authentication at the link layer is 
performed before IP address assignment. It is not suitable for 
network access over shared media (e.g., Ethernet, WLAN, cable). 
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Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


Terminology 
This document uses the following terms: 


Shared IPv4 address: An IPv4 address with a restricted Layer 4 
port set. 


Port Set ID (PSID): Identifier for a range of ports assigned to a 
DHCP client. 


Functional Overview 


Functionally, the dynamic allocation of shared IPv4 addresses by the 
DHCP 406 server is similar to the dynamic allocation process for 
"full" IPv4 addresses as described in [RFC2131]. The essential 
difference is that the DHCP 406 server can allocate the same IPv4 
address to more than one DHCP 406 client simultaneously, providing 
that each shared-address allocation also includes a range of Layer 4 
Source ports unique to that address (i.e., the combined tuple of IPv4 
address and Port Set ID is to be unique for each active lease). 


The DHCP 406 client implements OPTION V4 PORTPARAMS (described 
below), which is a DHCPv4 option containing PSID information. The 
client includes this option within the Parameter Request List option 
[RFC2132] in its DHCPv4 DHCPDISCOVER and DHCPREQUEST messages, 
indicating its support for shared, dynamic address leasing to the 
DHCP 406 server. 


OPTION V4 PORTPARAMS is also implemented by the server to identify 
clients that support shared, dynamic address leasing. With this 
option, the server can dynamically allocate PSIDs to clients and 
maintain shared IPv4 address leases. The server then manages unique 
client leases based on the IPv4 address and PSID tuple, instead of 
using only the IPv4 address. 


In the event that a client capable of dynamic, shared addressing 
receives more than one DHCP 406 offer, where a received offer does 
not contain OPTION V4 PORTPARAMS (i.e., it is an offer for a full 
IPv4 address), then the client SHOULD prefer the full IPv4 offer over 
the shared IPv4 address offer(s), unless specifically configured 
otherwise. 
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6. Client-Server Interaction 


The following DHCPv4 message flow is transported within the 
DHCPv4-query and DHCPv4-response messages as described in DHCPv4 over 
DHCPv6 [RFC7341]. 


1. When the client constructs the DHCPv4 DHCPDISCOVER message to be 
transported within the DHCPv4-query message, the DHCPDISCOVER 
message MUST include the client identifier option (constructed as 
per [RFC4361]) and the Parameter Request List option with the 
code OPTION V4 PORTPARAMS. The client MAY insert an 
OPTION V4 PORTPARAMS with preferred values in related fields as a 
suggestion to the DHCP 406 server. 


2. DHCP 406 servers that receive the DHCPDISCOVER message and 
support shared IPv4 addresses respond with a DHCPOFFER message 
with the shared IPv4 address in the yiaddr field, and they MUST 
add an OPTION V4 PORTPARAMS option containing an available 
restricted port set. If the DHCPDISCOVER included an 
OPTION V4 PORTPARAMS option containing a non-zero PSID-len field, 
the DHCP 406 server MAY allocate a port set of the requested size 
to the client (depending on policy). The DHCPOFFER message is 
then encapsulated in the DHCPv4-response message and sent to the 
client. 


3. The client evaluates all received DHCPOFFER messages and selects 
one (e.g., based on the configuration parameters received, such 
as the size of the offered port set). The client then sends a 
DHCPREQUEST encapsulated in the DHCPv4-query message containing 
the corresponding OPTION V4 PORTPARAMS received in the DHCPOFFER 
message. 


4. The server identified in the DHCPREQUEST message creates a 
binding for the client. The binding includes the client 
identifier, the IPv4 address, and the PSID. These parameters are 
used by both the server and the client to identify a lease in any 
DHCP message. The server MUST respond with a DHCPACK message 
containing OPTION V4 PORTPARAMS for the requesting client. 


5. On receipt of the DHCPACK message with the configuration 
parameters, the client MUST NOT perform an in-use probe on the 
address, such as ARPing for a duplicate allocated address. 


6. If the client chooses to relinquish its lease by sending a 
DHCPRELEASE message, the client MUST include the leased network 
address and OPTION V4 PORTPARAMS (with the allocated PSID) to 
identify the lease to be released. 
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In the case where the client has stored the previously allocated 
address and restricted port set, the logic described in Section 3.2 
of [RFC2131] MUST be followed on the condition that the client's 
Source IPv6 address for DHCP 406 does not change. Note that this 
corresponds to the INIT-REBOOT state defined in [RFC2131]. The 
client MUST include the OPTION V4 PORTPARAMS with the requested 
port-set information in the message flow, which starts with a 
DHCPREQUEST message. If the client's DHCP 406 IPv6 source address 
is changed for any reason, the client MUST re-initiate the DHCP 406 
shared-address provisioning process by sending a 

DHCPDISCOVER message. 


7. Client Behavior 


A DHCP 406 client sending a DHCPDISCOVER message for a shared IPv4 
address MUST include the OPTION V4 PORTPARAMS Option Code in the 
Parameter Request List option. If a client has previously been 
successfully allocated an IPv4 address and PSID, the client's 
DHCPDISCOVER message MAY include the Requested IP Address option 
along with an OPTION V4 PORTPARAMS to request that a specific IPv4 
address and PSID be reassigned. Alternatively, the client MAY omit 
the Requested IP Address option but include an OPTION V4 PORTPARAMS 
with a non-zero value in only the PSID-len field, as a hint to the 
server for the preferred size of the port set. 


A client that requests OPTION V4 PORTPARAMS but receives DHCPOFFER 
and DHCPACK messages without OPTION V4 PORTPARAMS SHOULD proceed as 
described in Section 9 of [RFC7341] and configure a full IPv4 address 
with no address sharing (see Section 8.1). 


When receiving a DHCPACK message containing OPTION V4 PORTPARAMS, the 
client MUST use the received explicit PSID for configuring the 
interface for which the DHCP 406 request was made. 


The client MUST NOT probe a newly received IPv4 address (e.g., using 
ARP) to see if it is in use by another host. 


When the client renews or releases its DHCP lease, it MUST include 
the offset, PSID length, and PSID values in OPTION V4 PORTPARAMS, and 
send it to the server within corresponding DHCPv4 messages. 


In the event that the client's DHCP 406 IPv6 source address is 
changed for any reason, the client MUST re-initiate the DHCP 406 
shared-address provisioning process by sending a DHCPDISCOVER 
message. 
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7.1. Restrictions to Client Usage of a Shared IPv4 Address 


As a single IPv4 address is being shared between a number of 
different clients, the allocated shared address is only suitable for 
certain uses. The client MUST implement a function to ensure that 
only the allocated Layer 4 ports of the shared IPv4 address are used 
for sourcing new connections or accepting inbound connections. 


The client MUST apply the following rules for all traffic destined 
to, or originating from, the shared IPv4 address: 


o The client MUST use only port-aware protocols (e.g., TCP, UDP, the 
Datagram Congestion Control Protocol (DCCP)) and be ICMP compliant 
with [RFC5508]. 


o All connections originating from the shared IPv4 address MUST use 
a source port taken from the allocated restricted port set. 


o The client MUST NOT accept inbound connections on ports outside of 
the allocated restricted port set. 


In order to prevent addressing conflicts that could arise from the 
allocation of the same IPv4 address, the client MUST NOT use the 
received restricted IPv4 address to perform ARP operations. 


The mechanism by which a client implements the above rules is out of 
scope for this document. 


In the event that the DHCPv4-over-DHCPv6 configuration mechanism 
fails for any reason, the client MUST NOT configure an IPv4 
link-local address [RFC3927] (taken from the 169.254.0.0/16 range). 


8. Server Behavior 


The DHCP 406 server MUST NOT reply with OPTION V4 PORTPARAMS unless 
the client has explicitly listed the Option Code in the Parameter 
Request List (Option 55) [RFC2132]. 


The DHCP 406 server SHOULD reply with OPTION V4 PORTPARAMS if the 
client includes OPTION VA PORTPARAMS in its Parameter Request List. 
In order to achieve dynamic management of shared IPv4 addresses, the 
server is required to implement an address and port-set pool that 
provides the same function as the address pool in a regular DHCP 
server. Also, the server uses the combination of address and PSID as 
the key for maintaining the state of a lease and for searching for an 
available lease for assignment. The leasing database is required to 
include the IPv4 address, PSID, and client identifier of the 
requesting client. 
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When a server receives a DHCPDISCOVER message with 
OPTION_V4_PORTPARAMS in the Parameter Request List option, the server 
determines an IPv4 address with a PSID for the requesting client. If 
an IPv4 address with a PSID is available, the server SHOULD follow 
the logic below to select which specific address and PSID to 
provision to the client. The logic is similar to that described in 
Section 4.3.1 of [RFC2131]. 


o The client’s current address with the PSID, as recorded in the 
client’s current lease binding, ELSE 


o The client’s previous address with the PSID, as recorded in the 
client’s (expired or released) binding, if that address with PSID 
is in the server’s pool of available addresses and PSIDs, and not 
already allocated, ELSE 


o The address requested in the Requested IP Address option along 
with the PSID parameters requested in the OPTION_V4_PORTPARAMS, if 
that pair of address and PSID is valid and not already allocated, 
ELSE 


o A new address with a PSID allocated from the server’s pool of 
available addresses and PSIDs. 


Upon receipt of a DHCPRELEASE message with OPTION_V4_PORTPARAMS, the 
server searches for the lease using the address in the ciaddr field 
and the PSID information in the OPTION_V4_PORTPARAMS, and marks the 
lease as unallocated if a record (matching that PSID) is maintained 
by the server for that client. 


The port-set assignment MUST be coupled with the address assignment 
process. Therefore, the server MUST assign the address and port set 
in the same DHCP message. 


When defining the pools of IPv4 addresses and PSIDs that are 
available to lease to clients, the server MUST implement a mechanism 
to reserve some port ranges (e.g., 0-1023) from allocation to 
clients. The reservation policy SHOULD be configurable. 
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8.1. Leasing Shared and Non-Shared IPv4 Addresses from a Single 
DHCP 406 Server 


A single DHCP 406 server may serve clients that do not support 
OPTION_V4_PORTPARAMS, as well as those that do. As the rules for the 
allocation of shared addresses differ from the rules for full IPv4 
address assignment, the DHCP 406 server MUST implement a mechanism to 
ensure that clients not supporting OPTION_V4_PORTPARAMS do not 
receive shared addresses. For example, two separate IPv4 addressing 
pools could be used, one of which allocates IPv4 addresses and PSIDs 
only to clients that have requested them. 


If the server is only configured with address pools for shared- 
address allocation, it MUST discard requests that do not contain 
OPTION_V4_PORTPARAMS in the Parameter Request List option. 


A server configured with non-shared address pools can be instructed 
to honor received requests that contain OPTION_V4_PORTPARAMS in the 
Parameter Request List option (that is, ignore OPTION_V4_PORTPARAMS 
and serve the requesting clients with non-shared IPv4 addresses). 


9. DHCPv4 Port Parameters Option 
The meanings of the offset, PSID-len, and PSID fields of the DHCPv4 


Port Parameters option are identical to those of the offset, 
PSID-len, and PSID fields of the S46 Port Parameters option 


(Section 4.5 of [RFC7598]). The use of the same encoding in both 
options is meant to ensure compatibility with existing port-set 
implementations. 


The format of OPTION V4 PORTPARAMS is shown in Figure 1. 


0 1 
Q^ Xe 32: 3e WE oie 26 b :8- 9 0* Xm 30-4 25 
R-—4R--—4R--4R--4R--4R--4R--4--4--4--4--4--4--4--4--4--4 


| option-code | option-len 

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
| offset | PSID-len | 
+—--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
| PSID | 


+-—+--4+--+--4+--+--4+--4+--4+--4+--4+--4+--+--4+--4+--4+--+ 
Figure 1: DHCPv4 Port Parameters Option 
Oo option-code: OPTION_V4_PORTPARAMS (159) 


oO option-len: 4 
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o offset: PSID offset. 8-bit field that specifies the numeric value 
for the excluded port range/offset bits ('a' bits), as per 
Section 5.1 of [RFC7597]. Allowed values are between 0 and 15, 
with the default value being 6 for MAP-based implementations. 
This parameter is unused by a Lightweight 4over6 client and should 
be set to 0. 


o PSID-len: Bit length value of the number of significant bits in 
the PSID field (also known as ’k’). When set to 0, the PSID field 
is to be ignored. After the first ’a’ bits, there are k bits in 
the port number representing the value of PSID. Subsequently, the 
address-sharing ratio would be 2^k. 


o PSID: Explicit 16-bit (unsigned word) PSID value. The PSID value 
algorithmically identifies a set of ports assigned to a client. 
The first k bits on the left of this 2-octet field indicate the 
PSID value. The remaining (16 - k) bits on the right are padding 
zeros. 


Section 5.1 of [RFC7597] provides a full description of how the PSID 
is interpreted by the client. 


In order to exclude the system ports ([RFC6335]) or ports reserved by 
ISPs, the former port sets that contain well-known ports MUST NOT be 
assigned unless the operator has explicitly configured otherwise 
(e.g., by allocating a full IPv4 address). 


Security Considerations 


The security considerations described in [RFC2131] and [RFC7341] are 
also potentially applicable to this solution. Unauthorized DHCP 406 
servers in the network could be used to stage an amplification attack 
or to supply an invalid configuration, leading to service disruption. 
The risks of these types of attacks can be reduced by using unicast 
DHCP 406 message flows (enabled by supplying DHCP 406 server unicast 
addresses within the OPTION DHCPA O DHCP6 SERVER option [RFC7341]). 


A malicious user could attempt a DoS attack by requesting a large 
number of IPv4 address (or fractional address) and port-set 
allocations, exhausting the available addresses and port sets for 
other clients. This can be mitigated by implementing, on each 
applicable customer site, a DHCP 406 address allocation policy that 
limits the number of simultaneously active IPv4 leases for clients 
whose requests originate from that customer site. 


The purpose of the client identifier option is to ensure that the 
same client retains the same parameters over time. However, this 
interferes with the client's privacy, as it allows the server to 
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Ts 


125 


12s 


track the client. Clients can manage their level of exposure by 
controlling the value of the client identifier, thereby trading off 
stability of parameter allocation for privacy. We expect that 
guidance on this trade-off will be discussed in a future version of 
[DHCP-Anonymity]. 


Additional security considerations are discussed in Section 10 of 
[RFC7597] and Section 9 of [RFC7596]. 


1. Port Randomization 


Preserving port randomization [RFC6056] may be more difficult because 
the host can only randomize the ports inside a fixed port range (see 
Section 13.4 of [RFC6269]). 


More discussion regarding improving the robustness of TCP against 
blind in-window attacks can be found in [RFC5961]. To provide 
protection against attacks, means other than (IPv4) source port 
randomization should be used (e.g., use [RFC5961] to improve the 
robustness of TCP against blind in-window attacks, or use IPv6). 


IANA Considerations 
IANA has assigned the following new DHCPv4 Option Code in the 


registry maintained at 
«http://www.iana.org/assignments/bootp-dhcp-parameters/»: 


Option Name Tag Data Meaning 
Length 
OPTION V4 PORTPARAMS 159 4 This option is used to configure a 
set of ports bound to a shared IPv4 
address. 
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